
Managing Pervasive Devices 



Field of the Invention 

The present invention relates to a management system for pervasive devices. 
Background of the Invention 

A brief overview of a prior art three tier management system is show^n in Figure 1. Here, a 
management server 10 communicates with management agent 12 resident on an endpoint 
computer workstation 14 (only one shown) via a gateway 16 (only one shown). 



A well known example of such a system is Tivoli s oftware - dist r ibu t i o i i and e tttetBris^ 
'-systems- manag e ment, art d-dctaitedrinformation about the features offered by Tivoli V3.6 are 
available athtt p://www -.r cdb o oks.ibm : c o m/pubo/pdfa/rcdbo o k ^ ^^ 



In a Tivoli system, each enabled endpoint 14 communicates with a gateway 16 via any 
peer-to-peer protocol, for example, TCP/IP, WX or.SNA. Communication between the server 10 



and the gateway 16 is via an OR^8',18'^^^^ere each endpoint connected to a gateway is 
addressed by the server through an associated object on the gateway ORB 18", thus enabling the 
endpoint to be directly addressed by the server. A management agent 12 known as a Lightweight 
Client Framework (LCF), resident on the endpoint, is thus accessible by the server and enables 
the server to push software via the gateway to the endpoint and call methods on applications 
resident on the endpoint. The server in turn runs programs 20, 22, 24 allowing: software to be 
selected for distribution to specified endpoints or defined groups of endpoints; endpoint software 
inventories to be obtained; and endpoint activity to be monitored via an Event Console, and these 
programs are extended for each endpoint platform to be managed. 
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1 While this management system has been quite successful, it should be noted that in order 

2 to control any endpoint 14, the endpoint must itself be manually enabled by installing the LCF 

3 client 12 on the endpoint and configuring the LCF client accordingly, for example, setting up its 

4 gateway address and communication protocol. 

5 At the same time more and more users are employing Tier 0 or pervasive devices 

6 ("devices") 26 including, for example, Palm Computing® platform devices ("Palm devices") 

7 from Palm Inc., a range of organizers from Psion pic and to a growing extent mobile and smart 

8 phones. Typically data on such pervasive devices 26 is managed locally by periodically 

9 connecting the pervasive device to a workstation 12 running a controller program 28 and 

10 synchronising one or more databases stored on the device, for example an address book, with 

if;| II corresponding databases stored on the workstation. 

12 In the case of a Palm device, a workstation application called HotSync® Manager 

Irii 13 controls the synchronisation of databases as well as the installation of new applications. HotSync 

m 14 uses one or more plug-ins known as conduits, each for exchanging and synchronising data 

L 15 between the workstation 14 and the Palm device 26. Most conduits synchronise data such that 

^ ^16 data on the device mirrors the data on the workstation, althougty others also transfer, 

hi 17 import/export data, or cause Palm applications to be installed. 

O 

•Jess. 

18 One of the default conduit modules (netcond.dll) responds to a user placing a Palm 

19 Network Configuration (.PNC) file in a pre-determined sub-directory prior to synchronisation. 

20 The file is copied to the device by the conduit module where it is used to update the script file for 
27 a modem. This, however, is extremely limited in terms of aspects of the device that may be 

22 configured. Also, the Palm desktop 28 includes a set-up menu, but this only enables a user to set 

23 workstation side modem and network parameters. If these are at odds with the Palm device, then 

24 errors can occur. 
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/ Because configuration facilities are so liniited, perhaps because of the problems of trying 

2 to access databases on the pervasive device which might be in use and so locked or unavailable, 

3 thus causing such facilities to operate unreliably, new users of pervasive devices may end up 

4 spending more time than is necessary manually configuring the devices before using them 

5 profitably. Even the provision of a configuration program per se is not as helpful as it might be, 

6 because if it is to avoid the problem of accessing databases which might be locked during 

7 synchronisation, it needs to run separately to device synchronisation and thus places an extra 

8 burden on the user. This also make the management of such devices within a tiered structure 

9 more difficult. 

10 If such pervasive devices are to be employed more efficiently within an enterprise, then 

J 77 they need to be quickly and easily configurable as well as capable of receiving and having 

^ 12 enterprise applications and data updated as seamlessly as possible, preferably, within the same 

""^l 75 framework used to manage other resources within the enterprise. 

%14 Summary of the Invention 

y 1 75 Accordingly the present invention provides a management system comprising a gateway 

fil 

yi}6 component adapted to reside on a workstation and a device agent adapted to reside on a 

^17 pervasive device for configuring pervasive devices; said gateway component being instantiable 

LI 

18 during synchronisation of said workstation with a pervasive device and comprising: means for 

79 transferring said device agent to said pervasive device; and means for transmitting configuration 

20 information to said pervasive device; and said device agent comprising means for executing 

27 configuration commands in response to said configuration information. 

22 The invention enables pervasive devices to be managed through a workstation to which 

23 they connect to synchronise without requiring any intervention by the pervasive device user. 

24 Preferably, the workstation acts as a gateway for managing the device within what becomes a 

25 four tier management system. 
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} Brief Description of the Drawings 

2 Embodiments of the invention will now be described with reference to the accompanying 

3 drawings, in which: 

4 Figure 1 is a schematic diagram of a prior art three tier management system; 

5 Figure 2 is a schematic diagram of a four tier management system for controlling 

6 pervasive devices; 

7 Figure 3 is a diagram of data stored on an endpoint through which Tier 0 Palm Pilot 

8 devices are managed according to the invention; and 

Cj 

-.,| 9 Figure 4 is a flow diagram illustrating the operation of an endpoint management gateway. 

Cfl 

^ 10 In the preferred embodiment of the present invention, Figure 2, the prior art management 

Cm — 

5 /; server is extended to provide respective inventory, software distribution and event console 

J^p 12 programs 20', 22', 24' for each pervasive device type to be managed by the system. 

'is? : 

nl 

\l\ 

|;i 13 It can be seen, however, that there are likely to be many more pervasive devices 26 than 

14 the endpoints 14 traditionally managed within such a system and so addressing each such device 

75 26 via a respective object on the gateway ORB 18" would be too onerous. The management 

16 system therefore treats such devices 26 as residing on a fourth tier in the management system, 

17 with each device being managed via an agent 30 resident on a suitably enabled endpoint. Thus, 

18 each enabled endpoint 14 acts as a management gateway for devices, 

19 The management server 10' employs a device storage manager 32 which contains the 

20 information about the device types and instances of devices being managed. For example, a 

21 device type of "Handheld Device" contains many instances of this type of device. This allows any 
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7 management server applications and users to add devices, edit devices, delete devices, and query 

2 for devices. Each such device in the system is identified by 5 pieces of information: 

3 1. Device Type 

4 2. ID - a unique identifier assigned by the system to each device 

5 3. Label - a friendly name for a device, specified at creation time. A Type plus a Label 

6 should uniquely define a device. 

7 4. Manager - the identity of an endpoint which is to act as a management gateway for this 

8 device. 

9 5. Local Address - the local address of a device in the context of its management gateway 

g= JO Manager is the gateway object reference through which to route management operations 

(using ¥iTc* method calls) toward a given device, thus the server-gateway ORB 18', 18" need 

y 1 

%II2 only handle the same number of object references as within a three tier management system. It 

fj|7i should therefore be seen that, even though the number and level of devices being managed within 

the system of the preferred embodiment is magnified, the use of a single ORB object not only to 

s 15 address the endpoint with which it was traditionally associated, but to manage essentially a 

HI J 6 hierarchy including an endpoint and a plurality of devices, prevents the endpoint addressing 

j -J/Z mechanism from collapsing from the sheer number of devices being controlled. 

^. 

IS Local Address is an address for a device at least unique in the context of its management 

79 gateway. So, using this information, it is possible to locate and manage any device in the 

20 management system. This scheme also allows for every device to have a unique ID and a unique 

27 friendly name (Label). 

22 -Beseriptien of tlie Pitrf eired-Embadimeftts- 

23 In the preferred embodiment, the device storage manager 32 encapsulates how the device 

24 data is stored and managed. Thus, the device storage manager and other applications such as the 
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7 programs 20', 22' and 24' only need to agree on a data exchange protocol so that messages can 

2 be exchanged. Using this mechanism, the management server 10' is able to support arbitrary 

3 Storage Manager implementations (e.g. disk files, LDAP servers, RDBMS) 
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Tivuli'^i management bv subscrintion naradi^m The device ffrour) also imnlements nolicv and 
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security for devices. Device groups can thus be made managed resources of Tivoli- Policy 




9 


Regions, and so it is possible to create custom policies for device group instances and to enforce 




10 


security models for devices through the Policy Region mechanism. By granting access to device 
groups on a per Policy Region basis, administrators may be selectively granted access to create 




•sa K' 


device groups, manage subscriptions to device groups, and to manipulate device groups 






distributions. This depends on roles each administrator holds in each Policy Region and is 




mi4 


normal ¥ivotr policy and security. 



> .* a 



m 

l-..^ 15 So, using the above methodology, the management system is able to identify endpoints 14 

W 16 which are to act as management gateways for pervasive devices 26, and the management of such 

III 

1=1 17 devices will now be discussed in relation to Palm devices in particular. 

?= <; 

o 

18 In order to enable endpoints as management agents for Palm devices, the endpoint 14 

19 must first have a Palm desktop 28 installed. This can be done either manually on the workstation 

20 14 or through the management server 10' deploying and running the Palm desktop installation 

21 software in a conventional manner. During installation of the Palm desktop on a Windows 

22 platform, certain changes are made to the Windows registry, Figure 3, in particular, to the 

23 HotSync Manager branch of the registry which includes two default conduits. Each conduit 

24 branch on an endpoint is given a name "Conduit x", where x is an ordinal number unique on the 

25 endpoint. Each conduit branch includes, inter alia, the following set of variables: 
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} Module, which tells HotSync which DLL program is associated with the conduit; 

2 Extensions which conventionally indicates to the DLL which file types it is to synchronise 

3 with the Palm device; 
4 

5 Directory tells the DLL the name of the device sub-directory in which to find the files to 

6 synchronise; and 

7 Creator ID which a special four character string associated with each conduit program. 

8 Conduit 1, is the install conduit and installs/synchronises Palm applications (.pre files) 

9 and databases (.pdb files) stored in an "install" sub-directory for a particular device. Every .pdb 
r;|70 database requires the .pre application that will access that database type. Where Palm Vn devices 
T^} and 3.2 Palm OS are being managed then Palm Query Applications (.pqa) files are also handled 
\''12 by the install conduit. 

m 
m 

ml3 Conduit 2, operates on Palm Network Configuration Files (*.pnc) also called Palm 

tJ4 Network Script Files (*.scp) stored in a "TCP" sub-directory for a particular device. The conduit 

Ul/5 module interprets the lines contained in the .pnc and ,scp files to execute on the device a 

restricted set of network operations like: "wait for", "Send", "Send CR", "Send User ID", "Send 

}:J77 Password", "Delay", "End". 

18 Once the desktop controller 28 is installed, an enabling program 34 and a management 

19 agent 30, TMPP.DLL, can be injected into the endpoint 14. The enabling program adds a further 

20 conduit branch to the registry. The program 34 detects installed conduits and if, as in the present 
27 example, only the default conduits are installed, the new conduit's name is set to "Conduit 4". 

22 This conduit's module is set to be the management agent 30, with a creator ID of "TIVO", which 

23 operates on files of extension. PCF stored in a "Tivoli" sub-directory for a device, Figure 3. 
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} At the same time users may already be connecting and synchronising unmanaged devices 

2 through the Palm desktop. When a device connects to an endpoint, it sets up a conduit mask 

3 defining which conduits are to execute when the device synchronises. Each conduit mask for a 

4 device comprises a Windows registry variable named "Installxxxx", whose value determines 

5 which of the defined conduits are to execute when HotSync executes for a device. The string 

6 xxxx is linked with the device directory name, from which the Install, TCP and Tivoli 

7 sub-directories depend, through the file Users.dat. So once a device is synchronising with an 

8 endpoint, the association of the conduit mask and the device directory name is maintained by the 

9 Palm Desktop and the Palm Desktop API exposes this relationship. This enables any program, 

10 such as the Palm Desktop itself or modules such as TMPP.DLL to a) locate the conduit mask for 

11 a device; b) locate the sub-directory in which Palm files are stored for a device being 

^,^12 synchronised; and c) determine the names of any devices (managed or unmanaged) connecting to 

"^13 the endpoint. 

ill 
%\ 

ct 

%l ii 

fu^4 At the management server 10', an enabled endpoint which is to act or acts as a 

;-;75 management agent for a device is either directly identified by a management server user, or the 

s 16 user can request specific endpoints or groups of endpoints to return the identities of devices that 

Li|77 a) they manage; or b) connect to the endpoint, even if they are not currently managed. In the 

preferred embodiment, these identities comprise a triplet of the form <label><manager><Palm 

O/P Desktop ID>. (The Palm Desktop ID comprises the Windows user ID of the owner of the Palm 

20 Desktop managing the device). 

27 Thus, the management server can seek out the identities of devices connected to enabled 

22 endpoints, add the identities of any unmanaged devices to the device storage manager 32 and 

23 then configure the associated endpoints to manage these devices. This configuration comprises 

24 updating the conduit mask for the device on the endpoint via the program 34 or by any other 

25 program injected into the endpoint, to cause the Tivoli conduit to execute during synchronisation. 
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/ So it will be seen that without any intervention either on the device or on its associated 

2 endpoint, other than the user simply synchronising their device as normal, the endpoint has been 

3 set up to manage the device from the server in a No-Touch manner. The types of management 

4 that can be carried out on the device correspond to those normally carried out on managed 

5 endpoints, that is, software distribution, inventory and event monitoring. In addition, the 

6 preferred embodiment, enables the management server to configure individual or groups of 

7 devices and to remove databases/applications from devices. 

8 Once a device 26 is associated with such an endpoint 14 which is to act as a management 

9 gateway, the simplest aspect of remotely and non-interactively configuring a Palm device via a 
10 tiered management structure is to distribute software applications. To deploy applications to the 

^.J] Palm device, the management server software distribution program 20' simply causes the 

^J2 appropriate .pre, .pdb and/or .pqa files to be placed in the Install directory for a device of group 

"^413 of devices. To do this, application files are supplied by the management server to an identified 

fi^I4 endpoint. An endpoint program in turn locates the appropriate Install sub-directory name for the 

Jjf 75 device label supplied (again using the Users.dat information accessed via the Palm desktop API) 

^ 16 and places the files in the sub-directory. When synchronisation next takes place with the device, 

c:i 

up? the install conduit copies these files from the device's Install sub-directory on the endpoint to the 

f'l 

IV8 device. It will be seen that this step requires no extra effort or intervention by the user of either 

y 79 the endpoint or the Palm device and so ensures that applications will be deployed to the Palm 

20 device at the very next opportunity, that is, the next synchronisation. 

^ 27 The -Ttvoir conduit module 30 acting as the management gateway for the device also 

22 performs the functions of carrying out a software inventory, notifying events, configuring the 

23 Palm device and removing applications from the Palm device. 

Dr 24 In the present embodiment, the Tlvol i- c onduit module TMPP.DLL is instantiated during 

25 synchronisation of a device, step 40, Figure 4. The module first checks the device to determine if 

26 an up-to-date copy of an agent Tivoli.prc 38 is available on the device. If not an up-to-date agent 
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is copied to the Palm device, step 42. It should be noted that the "fiveh conduit module does not 
rely on the Install conduit having copied Tivoli.prc to the device, as this would only make 
Tivoli.prc accessible to the install conduit module during that synchronisation cycle. If this 
approach were adopted, then either a second synchronisation cycle would be required or the 
install conduit module would need to be adapted to carry out the configuration otherwise 
performed by the Ttwii' conduit module. Nonetheless, should this restriction be lifted or not 
pertain for other device types, it would be possible to place the agent on the device using the 
install conduit and for the Tivel i conduit module to communicate with the agent thereafter. 

In any case, in the preferred embodiment, the T ivofr conduit module 30 then processes 
any device configuration information, step 44, previously supplied from the management server 
10' through the LCF 12 in the form of a .pcf file and placed in the Tivoli sub-directory for the 
device, step 46. It will be seen, however, that the configuration information can be supplied from 
any source, for example, a desktop user generated script file or via a desktop controller GUI. It 
should be noted that the conduit module can read from write locked device databases during 
synchronisation and this may be required to ascertain the version and thus the data structure of 
databases which are to be updated. Thus, during step 44, the conduit module can use the known 
structure of a database to be configured, to convert the configuration information into Palm 
device commands which it then writes to a device database Tivoli.pdb 39 again using the Palm 
desktop API, step 48. The conversion into Palm commands is done within the endpoint 14 as this 
both reduces the footprint required on the device and enables the PCF file to be written for more 
than one device independent of the versions of its databases. During synchronisation, the conduit 
module sets an alarm condition, step 50. The condition specifies the Tivoli agent service the 
alarm with the alarm passing to the agent 38 a launch code parameter indicating that it is to 
service an alarm. 

In the case of an alarm, the ¥i-vel4- agent executes the commands stored in the temporary 
database 39. Thus, when the *J4velt conduit module signals that synchronisation is complete, step 
52, the databases locked during synchronisation are released, and so the database updating 



GB920000048US1 



'JO- 




7 commands stored in the temporary database can be subsequently executed properly by the agent, 

2 step 54. Because the configuration commands execute automatically and immediately after 

3 synchronisation, it is also likely that the Palm device user will not be doing anything which is 

4 likely to lock a database, thus making configuration more likely to succeed. 

5 The Palm commands generated generally comprise a sequence of: open database, write 

6 value, close database, although some configuration may result in single conrnnands such as set 

7 network preference. In more detail, however, the syntax definition for the .pcf file is defined in 

8 Appendix A. (Some sections of the definition have been foreshortened for clarity with the deleted 

9 portions indicated by ellipsis.) This definition is stored in a local Tivoli.DEF file which is read 
10 and parsed by the conduit module, during step 44, thus enabling it t^ in turn^parse and process 

liyi the .pcf file. While the current definition is written to a bespoke grammar, it will be seen that the 

, ?« 

|l|/2 definition could be written in any suitable language, for example. Extended Mark-up Language, 

-jf/i which in turn could be parsed by an off-the-shelf parser incorporated in the conduit module. 

U^]4 Alternatively, the definition could be built into the conduit module, although this would make 

^ ' i 

0175 maintenance more difficult. 

^1\I6 It can be seen from the definition file that and 'T' are reserved characters, whose 

hp? function is explained below, and that text following pound (#) is ignored. According to the 

f\l8 syntax definition, .pcf files are divided into stanzas, each beginning with a label in square 

79 brackets, for example [SYSTEM]. Within each stanza, each line comprises an expression of the 

20 form "preference name = value". The conduit module associates each stanza label with either a 

27 database or a type of command, for example, [System] is associated with the "Saved preferences" 

22 database and [Network] is associated with the command "Set network preference". 

23 Some databases, such as "Saved preferences" have multiple known versions each with a 

24 respective data structure. When the conduit module reads a stanza label for such a database, it 

25 tries to identify which version and thus which data structure is used by the database. In the case 

26 of "Saved preferences", each version is stored in the first two bytes of the database. The current 
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/ syntax definition for SYSTEM allows the conduit module to operate with versions 3 to 7 of the 

2 Saved preferences database. For each version, the definition includes an associated sysStruct, 

3 telling the conduit module where variables are stored within the database. Each sysStruct element 

4 comprises a list of <preference name><offset><size> triplets, each separated by 'T' char. A 

5 negative value in <size> means a bit position at the specified offset. So, for example, when the 

6 conduit module reads from a database, it knows where to look for the version information, and 

7 can determine, for example, that version 5 of Saved Preferences is being used. The conduit then 

8 knows that, for example, "dateformat" can be set by writing the 3rd byte of the database to the 

9 required value. 

10 Each preference name can include a character, and the conduit module is hard coded 

P|/7 to recognise the string after the letting it understand that special processing is required for 

}l^2 that preference. 

yi 
in 

Possible values are separated by a semicolon, so for example, the first possible value for 

'^4 country is Australia and the next Austria. So, if a .pcf file included the following stanza: 

yi/5 [SYSTEM] 

I '^6 country = Austria 

77 and the Palm device were using version 5 of Saved Preferences, then the conduit would send the 

18 following (paraphrased) commands to the TivoU Agent for storage in the temporary database 39: 

J9 Open "Saved Preferences" 

20 Write 1 to location 2 

27 Close Database 

22 Each value can have aliases which are separated by "pipe" (I) char. So for example, the 

23 conduit will recognise that if "UnitedKingdom" or "United Kingdom" is specified, the same 
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1 country value will be written in Saved Preferences. Also, a char preceding a value means that 

2 it is the default value for that preference name. It means that a statement in the pcf file can 

3 indicate "preference name=default" and the value with the will be set on the preference name. 

4 Finally, some lists of values start with a char because the internal representation of the 

5 preference name starts counting from 1 rather than 0. The ";" char can thus be inserted or deleted 

6 from the beginning of the value list for a preference value in the definition file, to shift values 

7 between those set on the Palm device and the configured ones in the pcf file. 

8 Once the temporary database of configuration commands has executed, step 54, the agent 

9 finishes by deleting the temporary database and then optionally deleting itself, so removing any 
^,J0 management system presence on the Palm device. 

^ = =! 
Ml 

""^yi Another task of the conduit module is to cause applications and databases to be removed 

m 

p|/2 from the device. In the preferred embodiment, the management server places a .rmv file in the 

Tivoli sub-directory for the device. During synchronisation, the conduit module looks for such a 

^ J4 file and, if found, reads the file to identify the database/applications to be removed. It then 

ml 5 creates the appropriate Palm device commands and executes these, again through the Palm 

yV6 desktop API, step 58. The database/application remove commands are executed during 

077 synchronisation, in spite of the fact that the database/application may be locked. This is 

J8 considered beneficial as if it is not possible to delete such a database/application, then the conduit 

79 module can in turn report back to the management server Event Console. This should cause the 

20 management server user to think about why they wish to delete a database/application which is in 

21 fact in use. 

22 In the preferred embodiment, the ■ Tivoli 'device agent 38 can also be called during 

23 synchronisation. If the server program 22' requires an inventory of software on the device to be 

24 taken, then the agent is responsive to the conduit module 30 calling the agent 38 with a different 

25 launch code than that used for serving the alarm condition, step 56. The agent responds to this 
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inventory launch code, prepares an inventory and returns this to the workstation, from where it is 
returned to the server 10' in a conventional manner. 

The conduit module can also be extended notify any synchronisation events, such as the 
successful deployment of the database 39 or removal of databases, to the management server 
Event Console program 24', step 58, so ensuring that the complete range of management services 
for conventional endpoints can also be executed on pervasive devices. 



GB920000048US1 



-14- 



1 Appendix A 

2 [SYSTEM] 

3 # System preferences 

4 sysStruct[3]=lversionA2lcountry,2Jldateformat,3Jllongdateformat,4Jlw^ 

5 mat,6, 1 InumberformatJ, 1 lautooffduration,8, 1 Isyssoundlevelv20,9, 1 Igamesoundlevelv20, 10, 1 lalar 

6 msoundlevelv20, 11,1 Ihidesecretrecords, 12, 1 Idevicelocked, 13,1 llocalsyncrequirespassword, 14, 1 Ir 

7 emotesyncrequirespassword, 15,1 Isyspref flags, 16,2 Isysbatterykind, 18,1 lalloweastereggs, 19, 1 Iminu 

8 teswestofgmt,20,4ldaylightsavings,24,2lronamaticchar,26,2lhardlcharappcreator,28,4lhard2ch^ 

9 ppcreator,32,4lhard3charappcreator,36,4lhard4charappcreator,40,4lcalccharappcreator,44,4lh^^ 
10 adlecharappcreator,48,4llauncherCharAppCreator,52,4lhardcradle2charappcreator,56,4lanimation 

^.77 Level,60,2IDateAndTime,0,0ll 

lb 

yi 

\y2 sysStruct[4]=lversion,0,2l IDateAndTime,0,OII 

"^3 sysStruct[5]=lversion,0,2l lstaylitwhenpluggedin,77,llDateAndTime,0,OII 

s 

u 

11^4 sysStruct[6]=lversion,0,2lcountry,2,ll lantennacharappcreator,78,4IDateAndTime,0,0ll 

rll 

sysStruct[7]=lversion,0,2lcountry,2,ll lmeasurementsystem,82,2IDateAndTime,0,0ll 

16 country*ctry=Australia;Austria; ;UnitedKingdomlUnited Kingdom;UnitedStateslUnited 

17 States;India;Indonesia;Korea;Malaysia;RepChina;Philippines;Singapore;Thailand;Taiw^^ 

IS dateFormat=MDYWithSlasheslM/D/Y; ;MYMedlMMM •YY;MYMedNoPostlMMM YY 

79 IongDateFormat=MDYWithSlasheslMM/DD/YY; ;MYMedNoPostlMMM YY 

20 weekStartDay=SundaylSun;MondaylMon 
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timeFormat=Colonl 1 2HH:MM; ;Comma 1 2hl 1 2HH,MM 



numberFonnat=CommaPeriod;PeriodComma; . . . . ; ApostropheComma 

autoOffDuration=;l MinutelllOne MinutellM; ;3 MinutesBIThree MinutesBM 

sysSoundVolume*svl=Off;Low;Medium;High 
gameSoundVolume*sv2=Off;Low;Medium;High 
alannSoundVolume*sv3=Off;Low;Medium;High 
beamReceive*be=NolFalselOI*Off ; YeslTruel 1 lOn 
stayonwhenpluggedin=NolFalselOI*Off ; YeslTruel 1 lOn 
staylitwhenpluggedin=NolFalselOI*Off ; YeslTruel 1 lOn 
alloweastereggs=NolFalselOI*Off ; YeslTruel 1 lOn 
hidesecretrecords=NolFalselOI*Off;YeslTruelllOn 
DateAndTime*dt=*nowllocallPC 

# Following values for creators must be considered as default and not as a set of possible values. 
They are CASE SENSITIVE 

hardlcharappcreator*cr=*date 

hard2charappcreator'*=cr=*addr 

hard3charappcreator'*'cr=*todo 

hard4charappcreator*cr=*memo 

calccharappcreator*cr=*calc 

hardcradlecharappcreator*cr=*sync 

launcherCharAppCreator*cr=*lnch 

hardcradle2charappcreator*cr=*sync 

measurementSystem=unitsEnglishlinches;unitsMetriclmeters 

[NETWORK] 
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1 # Network Preferences. Note: all the settings for the services are done by pnc files. With the 

2 keyword of this section the service can enabled/selected. 

3 service*se=*Windows RAS 

4 [MODEM] 

5 # Modem Preferences 

6 modStruct[2]:=lversion,0,2lspeed,2,4lspeakervolume,6, 1 lpulse,7, 1 lflowcontrol,8, 1 lresetstring,9, 181 

7 initstring,28,8 1 lcountry,0,Olmodeniname,0,OII 

8 cDBStruct[0]=lniodeninanie,0,22lconnectionn[iethod,22,4lspeed,26,4ldefconf30JlisModeni,31J^ 

9 pulse,32, 1 lcountry,33, 1 lspeakervolume,34,2lflowcontrol,36,2lresetstring,38,8linitstring,46,8 1 II 

^0 country*co= Argentina; Australia; Austria; ;UnitedKingdomlUnited 

^;|/ Kingdom;UnitedStateslUnited States;*other 

IM 

"^2 connectionmethod*fv=*u8EZ 

pi 

^ 13 isModem=*falselno;truelyes 

modeniname*fvmo=*Standard 

rifj speed*sp=115200;*57600;38400;28800;19200;14400;9600;4800;2400;1200 

hi 

ri6 spe akervolu me=of f ; * lo w ; medium ; high 

"77 pulse=*touchtone;rotary 

18 flowcontrol=*auto;off;on 

19 initstring*fvis=*AT&FX4 

20 resetstring*fvrs=**NCl 

21 [HOTSYNC] 

22 # Hotsync Preferences 
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1 hotmStruct[ 1 ]=lversion,0,2lpad 1 ,2, 1 Imodemsyncpref ,3, 1 Ipad 1 ,4, 1 !hotsynctype,5, 1 llocalconnectio 

2 n,6,22lmodemdirectConnection,28,22lmodemnetservice,0,0lprimaiypcname,0,^ 

3 hotpStmct[2]=ldiaIprefix,2,-8ldisablecallwaiting,2,-7lusecallingcard,2,-6lmodemdirectphon^ 

4 dialprefixvalue,45 ,4 1 ldisablecallwaitingvalue,86,4 1 luseCallingCardvalue, 1 27,4 1 II 

5 modemDirectPhone* f v=*00 

6 dialprefix='''falselno;truelyes 

7 dialprefixvalue*fv=*9, 

8 disablecallwaiting=*falselno;truelyes 

9 disablecallwaitingvalue*fv=* 1 170, 
10 usecallingcard=*falselno;truelyes 

7 7 usecallingcardvalue*fv=*„„ 




modeinDirectConnection*fvdc=*Palm V Modem # only PalmOS 3.3 and later 



modemNetService*fvns=*Windows RAS 



localConnection*fvlc=*Direct SerialllR to a PC/Handheld 




hotsyncType*hsty=*local;modem 
modemSyncPref=*network;modem 
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LANSyncPref*ls=locallfinal;LANSynclproxy 
primaryPcName*fvpn=*localhost 
primaryPcAddress*fvpa=* 127.0.0. 1 
primaryPcSubnetMask*fvps=*255. 255. 255.0 



27 



[AUTOPALM] 



23 



22 



makeimage*pwmi=*h:/Palm/image 
pcfname*pwpn=*_delta_.pcf 



26 



24 



25 



# if a path isn't specified, the file is created in image dir 
makepcf*pwmp=*h:/Palm/image 

set*pwsb=0:0:0@0,0 #Card:DB:Rec@Offset,byte,byte@Offset,byte.... 
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